By Rodrigo Mendez Gamboa
Department Head Research & Architecture

The Basics

At the beginning of the internet era, you usually only had a server (usually a physical one, a big PC in your office connected to the internet). This server ran some kind of application, maybe a PHP script that generated a webpage, or just a webserver serving static files.

Your clients accessed your server by typing “yourcompany.com” in their web browser, getting your actual server IP address and directly connecting to it.

This sounds simple enough, right? But when the Internet, websites, and eventually applications, started increasing in popularity, adoption and sophistication, problems began to arise.

Scalability

Let’s say that our website became a hit, and suddenly we started getting thousands, or tens of thousands of visitors at once, what would happen? Well, usually the server would lock up because it was out of resources.

What’s the solution? The first logical thing to do is to get a bigger server, with more RAM, a better processor, etc. But there was a limit to how big a server can be, based on the available technology of the time. This approach is called Vertical Scaling.

Another way to solving this problem is having several servers working in parallel, sharing the load of your web application. This approach is called Horizontal Scaling and is the method more commonly used nowadays.

Software maintenance and evolution

Now, let’s say that our humble webpage came of age and now we have features that require user sign up, sending email notifications, creating posts, uploading pictures, hosting videos, etc.

Our original codebase has grown greatly since we started and has become a gigantic mess. Now our developers don’t want to add new features for fear they may break something, and making any change becomes very time-consuming and expensive.

How can we solve this?

You may have heard about Microservices. They have risen in popularity and today are one of the most common software development methods out there. They are an architectural way of structuring the web application backend by dividing it into several small pieces that specialize in solving a specific problem well. Microservices bring better flexibility, scalability, maintainability, and faster development iterations to an application, making it possible to have several independent teams of developers working on new features without affecting each other.  The drawback to consider, though, is this can lead to higher overall complexity.  Put simply, microservices allow for simpler decoupled parts, but involve more complex orchestration and setup.

Hosting and server maintenance

Another thing to note here is that most companies now have migrated their servers from their own premise to the Cloud, renting physical or virtual servers from companies such as AWS, Azure, and Google Cloud.

Choosing an enterprise architecture

Now that we have talked about some of the main considerations when designing an enterprise app architecture, let’s recap about our decisions:

• For scalability, we will be using Horizontal Scaling
• For overall system architecture, we will be using Microservices
• For hosting, we will use a Cloud provider

Now, how do we set up all required servers for horizontal scalability? How do we know how many we will need? How do we set up and deploy all our microservices? How do we create the resources required in our Cloud Provider?

This seems daunting, doesn’t it? Having a single server in our office looked so much more straightforward, right?

To solve this, we need a higher-level abstraction, a framework we can use to solve those problems and not get lost in the details.  We need to stop thinking at the individual server level and start thinking at a higher overall architecture level, and delegate the details to a tool or a platform.

Here is where solutions like Serverless approaches and Kubernetes come into play.

Serverless

As the name implies, this approach is about forgetting servers and all the complexities involved in maintaining them. The key here is taking advantage of managed solutions provided by our Cloud provider as much as possible.

For example, instead of having a Linux server running nginx and some node.js microservices, we can use AWS API Gateway, and AWS Lambdas that run our code, and have a managed database like AWS RDS.

Some advantages here are: no need to set up the software on the server, no need to maintain it (apply updates for software vulnerabilities, etc.), and easier configuration thanks to the UI work on the AWS console.

Scaling is easier too because we do not create actual servers. AWS Lambda instances are automatically created and destroyed as they are needed, also bringing cost savings if our application is only used periodically.

Now, we also need to consider some disadvantages. First, not all applications may work well on a serverless approach, especially if you need any live data, or do heavy computing on the backend, because of how AWS Lambdas work, there are limitations on what they can do and how long they can run. Also, sometimes you may see some delay between a request and getting a response, because the creation of a new lambda instance may take some time, especially if your software becomes massive.

Also, you will have to adapt your software to take advantage of your cloud provider managed services, which ties you deeper to that cloud provider, making it harder to migrate if needed in the future.

For working with Serverless architectures, we recommend using the Serverless Framework (https://www.serverless.com), as it eases and automates a lot of work on configuring and deploying the software.

Kubernetes

Kubernetes is a technology originally started by Google developers, based on how Google manages their services internally.

It allows you to define your Microservices architecture in a programmatic way, abstracting away everything that has to do with scaling, deploying, inter-service communication, and networking.

It works by setting up a cluster of several servers (or use a managed cluster service like EKS), and then communicates with the cluster using a command line application, applying changes defined in code.

Some cloud providers like AWS also support auto scaling the cluster (adding or removing servers as they are needed), which is also managed by Kubernetes.

One major difference between Serverless and Kubernetes is that here you have actual servers, but the management of those is abstracted away by the Kubernetes tooling.

A couple of drawbacks to Kubernetes to keep in mind are: (1) learning the Kubernetes tooling and concepts can be daunting as there is a lot of information to digest, and (2), the cost of the cluster is less granular and tends to start higher than a Serverless application.

Cost Implications of Both

Speaking of costs, let’s dig into that a little deeper. So, serverless tends to start low, but if you have consistent high traffic, the cost grows quickly, while with Kubernetes, cost starts high, but then grows more slowly and predictably with more traffic. For example:

Let’s say we have an application that is getting 3 million requests a month, running with 512MB of memory and with an average request execution time of 300ms, the cost would be:

• For Serverless with AWS Lambda: $8/month
• For Kubernetes: $160/month (most of the cost here is due to the required Kubernetes Control Plane, needed to manage the Cluster)

But now, let’s say that we grow to 90 million requests a month, cost changes to:

• For Serverless with AWS Lambda: $206/month

• For Kubernetes: $173/month

So, which one should I use?

The specific requirements of your application need to be considered before choosing one approach, but here are some general rules of thumb to consider:

• If you need to get going quickly, have almost no maintenance overhead, you do not have dependencies on legacy software, and your application traffic is not predictable, go with Serverless in AWS Lambda.
• But if you have dependencies on legacy software or software that doesn’t run in Lambda, or your application traffic is predictable and high, or you require advanced features like live data, extensive computing, or fast and predictable request responses, go with Kubernetes.

I hope you have a better feel for the benefits and drawbacks of Serverless and Kubernetes after reading this article, and that you’re more knowledgeable about which solution is right for you.

If you are facing this decision and still have questions or doubts, I’d personally love to help you think through your challenge.  We’ve helped hundreds of customers through this decision, and challenges like it, and we’d love to help you too. 

Click here to submit your question or challenge and reference this article and I’ll respond right away.

Let’s schedule a call